home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group V. Cerf
- Request for Comments: 1052 NRI
- April 1988
-
- IAB Recommendations for the Development of
- Internet Network Management Standards
-
- Status of this Memo
-
- This memo is intended to convey to the Internet community and other
- interested parties the recommendations of the Internet Activities
- Board (IAB) for the development of network management protocols for
- use in the TCP/IP environment. The memo does NOT, in and of itself,
- define or propose an Official Internet Protocol. It does reflect,
- however, the policy of the IAB with respect to further network
- management development in the short and the long term. Distribution
- of this memo is unlimited.
-
- Background
-
- At the IAB meeting on 21 March 88 in videoconference, the report of
- the Ad Hoc Network Management Review Committee was reviewed. The
- recommendations of the committee were endorsed by the IAB and
- direction given to the chairman of the Internet Engineering Task
- Force to take the necessary steps to implement the recommendations.
-
- The IAB expressed its gratitude for the efforts of the HEMS, SNMP and
- CMIP/CMIS working groups and urged that parties with technical
- interest in the outcome of the network management working groups
- convey their ideas and issues to the relevant working group chairmen.
-
- The IETF chairman was directed to form two new working groups, one of
- which would be responsible for the further specification and
- definition of elements to be included in the Management Information
- Base (MIB). The other would be responsible for defining extensions
- to the Simple Network Management Protocol to accommodate the short-
- term needs of the network vendor and operator communities. The
- longer-term needs of the Internet community are to be met using the
- ISO CMIS/CMIP framework as a basis. A working group of the IETF
- exists for this work and would continue its work, coordinating with
- the two new groups and reporting to the IETF chairman for guidance.
-
- The output of the MIB working group is to be provided to both the
- SNMP working group and the CMIS/CMIP ["Netman"] working group so as
- to assure compatibility of monitored items for both network
- management frameworks.
-
-
-
-
-
- Cerf [Page 1]
-
- RFC 1052 Internet Management April 1988
-
-
- Specific Recommendations
-
- The IAB recommends that the Simple Network Management Protocol be
- adopted as the BASIS for network management in the short-term.
- Extensions may be required to the existing SNMP specification to
- accommodate additional data types or to deal with functional or
- performance issues arising as multiple SNMP implementations are
- deployed and applied, especially in multi-vendor applications.
-
- The SNMP working group constituted by the IETF is charged with
- considering requirements not met by the present SNMP definition,
- defining extensions, if necessary, to accommodate these needs, and
- preparing revisions of the SNMP specifications to address any new
- extensions.
-
- The IAB urges the working group to be extremely sensitive to the need
- to keep SNMP simple, to work quickly to come to concensus on any
- revisions needed and to promulgate expeditiously the results of its
- work in one or more RFCs within the next 90 days. The IETF chairman
- is responsible for resolving disagreements arising if they cannot be
- resolved within the working group and is instructed to escalate
- problems quickly to the IAB should resolution not be forthcoming.
-
- The IAB further recommends that the MIB working group begin its work
- equally expeditiously, taking as its starting inputs the MIB
- definitions found in the existing High-Level Entity Management
- Systems (HEMS) RFC-1024, the SNMP IDEA-11, and CMIS/CMIP IDEAs.
-
- It is the intention of the IAB that the MIB definitions be applied
- both to the SNMP system in the short term and CMIS/CMIP for TCP/IP in
- the longer term. The three working groups will have to coordinate
- their efforts carefully to achieve these objectives:
-
- 1. Rapid convergence and definition for SNMP.
-
- 2. Rapid convergence and definition for the TCP/IP MIB.
-
- 3. Provision for transitioning from SNMP to CMIP/CMIS.
-
- 4. Early demonstration of the CMIP/CMIS capability using the
- TCP/IP MIB.
-
- The IAB remains extremely interested in progress towards these goals
- and intends to have representation, whenever possible, in the various
- working group and IETF plenary activities.
-
-
-
-
-
-
- Cerf [Page 2]
-
- RFC 1052 Internet Management April 1988
-
-
- REPORT OF THE AD HOC NETWORK MANAGEMENT REVIEW COMMITTEE
-
- Edited by Vinton Cerf, Chairman
-
- March 1988
-
- EXECUTIVE SUMMARY
-
- On 29 February 88, an ad hoc committee was convened to review the
- network management options for the Internet in particular and the
- TCP/IP protocol suite in general. This meeting was called at the
- request of the Internet Activities Board in the course of exercising
- its responsibilities to the Federal Research Internet Coordinating
- Council (FRICC) and by the MITRE Corporation as a consequence of its
- work for the U.S. Air Force on the ULANA project.
-
- At the conclusion of the one day meeting, it was agreed that the
- following recommendations be forwarded to the Internet Activities
- Board chairman, Dr. David C. Clark, for consideration at the next IAB
- meeting scheduled for 21 March:
-
- 1. In the short term, the Internet community should adopt and
- adapt the Simple Network Management Protocol (SNMP) for use as the
- basis of common network management throughout the system.
-
- (Rationale: The software is available and in operation.)
-
- 2. In the longer term, the Internet research community and the
- vendors should develop, deploy and test a network management
- system based on the International Standards Organization (ISO)
- Common Management Information Services/Common Management
- Information Protocol (CMIS/CMIP).
-
- (Rationale: The Internet community can take the high ground in
- protocol development by virtue of the experimental environment in
- which it can operate. Recommendations to the ISO from this
- community, the IAB and the vendors will carry great weight if they
- are in the language of the ISO common network management system
- and if they are rooted in actual experience with implementation
- and use in the field.)
-
- 3. Responsibility for the SNMP effort should be placed in the
- hands of an IETF task force.
-
- (Rationale: Eliminate vendor-specific bias or control over the
- SNMP and its evolution and harmonize inputs from the Internet
- community.)
-
-
-
-
- Cerf [Page 3]
-
- RFC 1052 Internet Management April 1988
-
-
- 4. As a high priority effort, define an extended Management
- Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into
- closer conformance with the MIB defined for the experimental
- HighLevel Entity Management System (HEMS).
-
- (Rationale: The HEMS effort produced a very thorough and widely-
- discussed set of elements to monitor, along with definitions of
- the semantics of these elements. The current SNMP definitions are
- more restricted and the CMIP definitions less precise.
- Implementation of SNMP in a timely and useful fashion through the
- Internet cannot be satisfactorily completed without such a
- definition of information elements in hand.)
-
- The ad hoc committee therefore recommends immediate action by the
- IAB on all four of these points. It should be noted that this
- resolution would not have been possible in such a timely way
- without the statesman-like efforts of Craig Partridge who, at the
- end of the day, recommended that the HEMS effort be withdrawn from
- consideration so as to pave the way for an Internet-wide
- agreement. In consideration of this unselfish act, the ad hoc
- committee urges the IAB to approve the recommendations above and
- to instruct the IETF to move quickly to accept and act on the SNMP
- items requiring completion.
-
- 1. INTRODUCTION
-
- During its development history, the community of researchers,
- developers, implementors and users of the DARPA/DoD TCP/IP protocol
- suite have experimented with a wide range of protocols in a variety
- of different networking environments. The Internet has grown,
- especially in the last few years, as a result of the widespread
- availability of software and hardware supporting this system. The
- scaling of the size and scope of the Internet and increased use of
- its technology in commercial applications has underscored for
- researchers, developers and vendors the need for a common network
- management framework within which TCP/IP products can be made to
- work.
-
- In recognition of this need, several efforts were started to develop
- network management concepts which might be applied to the Internet
- and to the internet technology in general. Three of these efforts
- had made sufficient progress by the end of 1987 that it became clear
- that some choices had to be made or the community would find itself
- with a set of incompatible network management tools. These efforts
- included the High-Level Entity Management System (HEMS), the Simple
- Gateway Monitoring Protocol (SGMP) and the Common Management
- Information Service/Protocol.
-
-
-
-
- Cerf [Page 4]
-
- RFC 1052 Internet Management April 1988
-
-
- The latter is an ISO initiative which was adapted to Internet use in
- a vendor-initiated effort. The HEMS work was carried out in the
- context of the Gateway Monitoring group of the Internet Engineering
- Task Force. The SGMP effort was carried out largely in the practical
- context of the NYSERNET and SURAnet regional networks which needed
- network management facilities to operate satisfactorily.
-
- Independent of the general Internet situation and requirements, the
- U.S. Air Force has been pursuing a Universal Local Area Network
- Architecture (ULANA) for its own use. The principal agent for the
- development of the ULANA specifications is the MITRE Corporation.
- Faced with several long and short term network management options,
- the MITRE ULANA specification team initiated an effort with
- substantial vendor participation called the NETMAN working group.
-
- It was against this fabric of various options that the IAB appointed
- a chairman to convene a review committee to discuss these various
- options and to make recommendations on long and short term choices.
- The MITRE Corporation co-sponsored this work to further its aims in
- the specification of the ULANA design.
-
- Reference material listed at the end of this report was provided in
- advance of the meeting.
-
- 2. DISCUSSION
-
- Rather than attempting to produce minutes of the meeting, this
- section summarizes in very high level terms the substance of the
- discussion which took place during most of the meeting. Presentation
- viewgraphs can be made available to IAB/FRICC members interested in
- their contents.
-
- The agenda was followed fairly closely with the technical
- presentations made in the order suggested: HEMS, SGMP, CMIP/CMIS.
-
- The HEMS effort has established a benchmark for other network
- management work in the sense that it took a comprehensive conceptual
- view of the problem and went into considerable detail on the design
- of the underlying management information database, the mechanics of
- access to and reporting of information, considerations of scaling and
- performance (e.g., Query Language vs Remote Procedure Call style),
- definition of information required and so on. HEMS has been
- implemented in an experimental version from which some encouraging
- performance measurements were taken. Serious vendor interest in this
- protocol was expressed by Cisco Systems and implementation efforts
- were under way as of the meeting.
-
- The SGMP effort, though somewhat less documented, was rooted in a
-
-
-
- Cerf [Page 5]
-
- RFC 1052 Internet Management April 1988
-
-
- practical need for network management tools for the NYSERNET,
- SURAnet, and, by extension, other components of the Internet.
- Implementations of it exist, in its RFC-1028 form (probably with some
- experimental extensions based on experience gained from the initial
- work), and are in use today. Serious vendor support for this work is
- found at Proteon and, more recently, in the NSFNET effort by MERIT,
- IBM and MCI, specifically in the IBM Network Switching System (NSS)
- nodes. Applications running above SGMP exist and provide useful
- monitoring information, presented in easily grasped form.
-
- The ISO CMIS/CMIP effort, voluminously documented, has had almost no
- implementation as yet. Reports from Unisys/SDC about an experimental
- implementation were heard at the meeting. There is substantial
- momentum in the international community for the adoption of this
- service and protocol suite for network management. The Draft
- Proposal is out for its second ballot (it failed to make Draft
- International Standard on its first ballot). There is vocal vendor
- support for this work, based on the premise that ultimately the ISO
- protocol suite will propagate and the vendors must support it.
-
- In general, all of the network management proposals make use of the
- Abstract Syntax Notation 1 (ASN.1) which has emerged from the ISO
- efforts as a kind of lingua franca for the representation of
- arbitrary data structures. The data types used in the SGMP
- Management Information Base (aspects of network components to be
- monitored) are the most restricted of the three proposals, confined
- to integers and octet strings only. HEMS has the most extensive
- Management Information Base and added some rather unique ideas such
- as self-knowledge about what could be monitored so that a
- device/unit/component could respond to a query asking "what can you
- tell me about yourself and your operation and how is it represented?"
- (!). CMIS/CMIP is probably the broadest in scope, but less precisely
- defined at this point, with respect to information which should be
- monitored. The draft RFCs referenced above relating to the CMIS/CMIP
- concerning items to be monitored are still in the definition stages.
-
- A point made strongly by the HEMS team was their concern that a
- Remote Operations basis for CMIP may not scale well into a very large
- Internet which needs to be monitored from a few central sites.
- Remote Operations is a term used by ISO and means, roughly, what the
- Internet community has long referred to as Remote Procedure Calls.
- If each atomic action is a Remote Procedure Call, the HEMS team
- argues that increasing Internet size and potential delays may vastly
- constrain the amount and timeliness of information which can be
- collected. The HEMS design uses, instead, a general query language
- approach which permits more elaborate, multi-variable queries to be
- formulated at the requesting site and processed at the responding
- site(s).
-
-
-
- Cerf [Page 6]
-
- RFC 1052 Internet Management April 1988
-
-
- Although it does substantial injustice to the very lucid and helpful
- presentations by representatives of each of the network management
- research groups, I have chosen to leave out much of the detail from
- this report and move directly to the points of agreement which were
- reached by the Committee.
-
- 3. POINTS OF AGREEMENT
-
- (i) Future Internet development is a joint interest of the R&D
- community, the vendor community and the user community.
-
- [Editor's comment: The development of the Internet is now not only
- dependent on research work, but on the hardware and software of
- vendors selling to both commercial ("internet") and the research
- environment ("Internet"). Moreover, the Internet users are not all
- concerned with network research; many of the components of the
- Internet are based on vendor-supplied and supported subsystems.]
-
- (ii) We still don't have a common understanding of what
- [Inter]Network Management really is.
-
- [Editor's comment: We haven't tried to manage the Internet as a
- collection of autonomous systems in an effective way, yet.]
-
- (iii) We will learn what [Inter]Network Management is by doing it.
-
- (a) in as large a scale as is possible
-
- (b) with as much diversity of implementation as possible
-
- (c) over as wide a range of protocol layers as possible
-
- (d) with as much administrative diversity as we can stand.
-
- (iv) There are more than HEMS, SGMP and CMIS/CMIP as potential
- candidates:
-
- HEMS, SGMP, CMIS/CMIP [multiple profiles], NETVIEW,
- LANMANAGER, Network Computing Forum "Fat Document"...
-
- [Editor's comment: The multiplicity of options is motivation for
- coalescing the energy of the Internet environment around single short
- and long term foci so as to make more substantial progress in really
- understanding network management per point (iii).]
-
- (v) Define the Management Information Base for TCP/IP suite NOW!
-
- (vi) Seek a seat for IETF on ANSI, ISO and/or CCITT!!!
-
-
-
- Cerf [Page 7]
-
- RFC 1052 Internet Management April 1988
-
-
- [Editor's comment: This may actually be feasible.]
-
- (vii) Define a CMIS interface to any of the surviving network
- management schemes so as to provide a migration path to ISO.
-
- 4. RESOLUTION AND CONCLUSIONS
-
- In a dramatic act of statesmanship, Craig Partridge volunteered that
- the HEMS proposal be dropped in favor of the other two efforts, SGMP
- and CMIS/CMIP - IF THIS WOULD LEAD TO INTERNET-WIDE AGREEMENT ON A
- NETWORK MANAGEMENT PLAN FOR THE SHORT AND LONG TERM.
-
- A rationale for the long term was proposed, based on the assumption
- that the ISO initiatives, and the U.S. Government issuance of the
- GOSIP guidelines, would ultimately require at least the Government
- users, and hence their vendor suppliers, to use ISO-based protocols
- and tools. In this rationale, the Internet research community and its
- vendors would "take the high ground" in network management by
- implementing the CMIS/CMIP on top of the TCP/IP protocol suite and
- deploy it widely for experimental use in the Internet.
-
- Neither the ISO nor any other organization, including the Corporation
- for Open Systems (COS) has anything close to the laboratory in large
- that the Internet represents. By taking the initiative, the Internet
- working groups can establish credibility based on experience which
- will make it far more feasible to affect the evolution of the ISO
- network management and other related efforts. The Internet community
- will be able to speak with authority about problems with the design
- or definition of CMIS/CMIP based on real implementation experience
- and use, rather than solely analytic means.
-
- In the short term, however, the Internet desperately needs tools to
- apply to the operational management problems associated with its
- rapid growth. Given the present state of advanced implementation of
- the SGMP and its relative simplicity, the general agreement was that
- SGMP (or its re-named successor, SNMP) should be quickly brought to
- more complete specification for widespread implementation and use.
-
- In short, the ad hoc committee recommends:
-
- 1. In the short term, the Internet community should adopt and
- adapt the Simple Network Management Protocol (SNMP) for use as the
- basis of common network management throughout the system.
-
- (Rationale: The software is available and in operation.)
-
- 2. In the longer term, the Internet research community and the
- vendors should develop, deploy and test a network management
-
-
-
- Cerf [Page 8]
-
- RFC 1052 Internet Management April 1988
-
-
- system based on the International Standards Organization (ISO)
- Common Management Information Services/Common Management
- Information Protocol (CMIS/CMIP).
-
- (Rationale: The Internet community can take the high ground in
- protocol development by virtue of the experimental environment in
- which it can operate. Recommendations to the ISO from this
- community, the IAB and the vendors will carry great weight if they
- are in the language of the ISO common network management system
- and if they are rooted in actual experience with implementation
- and use in the field.)
-
- 3. Responsibility for the SNMP effort should be placed in the
- hands of an IETF task force.
-
- (Rationale: Eliminate vendor-specific bias or control over the
- SNMP and its evolution and harmonize inputs from the Internet
- community.)
-
- 4. As a high priority effort, define an extended Management
- Information Base (MIB) for SNMP and TCP/IP CMIP to bring them into
- closer conformance with the MIB defined for the experimental
- HighLevel Entity Management System (HEMS). (Rationale:
- The HEMS effort produced a very thorough and widely-discussed set
- of elements to monitor, along with definitions of the semantics of
- these elements. The current SNMP definitions are more restricted
- and the CMIP definitions less precise. Implementation of SNMP in a
- timely and useful fashion through the Internet cannot be
- satisfactorily completed without such a definition of information
- elements in hand.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Cerf [Page 9]
-
- RFC 1052 Internet Management April 1988
-
-
- MEMBERS OF THE AD HOC NET MANAGEMENT REVIEW COMMITTEE
-
- Amatzia Ben-Artzi
- Sytek Corp.
- 1225 Charleston Rd.
- Mountain View, CA 94043
- Amatzia@amadeus.stanford.edu
-
- Bob Braden
- USC-ISI
- 4676 Admiralty Way
- Marina del Rey, CA 90292
- braden@isi.edu
-
- Jeff Case
- University of Tennessee
- 200 Stokely Management Center
- Knoxville, TN 37996
- case@utkcs2.cs.utk.edu
-
- Vint Cerf - Chairman
- Corp. for National Research Initiatives
- 1895 Preston White Dr., Suite 100
- Reston, VA 22091
- (703) 620-8990
- Cerf@ISI.EDU
-
- Chuck Davin
- Proteon, Inc.
- 2 Technology Dr.
- Westborough, MA 01536
- jrd@monk.proteon.com
-
- Stephen Dunford
- UNISYS Corp.
- System Development Corporation
- 5151 Camino Road
- Camarillo, CA 93010
- dunford@cam.unisys.com
-
- Mark Fedor
- NYSERNET
- 125 Jordan Road
- Troy, NY 12180
- fedor@nisc.nyser.net
-
-
-
-
-
-
- Cerf [Page 10]
-
- RFC 1052 Internet Management April 1988
-
-
- Phill Gross - IETF Chairman
- MITRE Corporation
- 1820 Dolley Madison Blvd.
- McLean, VA 22012
- Gross@Gateway.MITRE.Org
-
- Lee LaBarre
- MITRE Corporation
- Burlington Road
- Bedford, MA 01730
- cel@mitre-bedford.arpa
-
- Dan Lynch
- Advanced Computing Environments
- 480 San Antonio Rd.
- Mountain View, CA 94040
- Lynch@isi.edu
-
- Jim Mathis
- Apple Computer, Inc.
- MS 27-0
- 20525 Mariani Ave.
- Cupertino, CA 95014
- Mathis@Apple.com
-
- Craig Partridge
- BBN Labs
- 10 Moulton St.
- Cambridge, MA 02238
- craig@bbn.com
-
- Marshall T. Rose
- The Wollongong Group, Inc.
- 1129 San Antonio Road
- Palo Alto, CA 94043
- MRose@twg.com
-
- Greg Satz
- Cisco Systems
- 1360 Willow Rd., Suite 201
- Menlo Park, CA 94301
- satz@cisco.com
-
- Martin Lee Schoffstall
- NYSERNET
- 125 Jordan Road
- Troy, NY 12180
- schoff@nisc.nyser.net
-
-
-
- Cerf [Page 11]
-
- RFC 1052 Internet Management April 1988
-
-
- Glenn Trewitt
- Center for Integrated Systems, Room 216
- Stanford University
- Stanford, CA 94305
- Trewitt@amadeus.stanford.edu
-
- MEETING LOCATION: San Diego Supercomputer Center, UC San Diego
-
- LOCAL ARRANGEMENTS: Paul Love, SDSC
-
- MEETING DATE: 29 February 1988
-
- AGENDA ITEMS:
-
- 0900 Introductions and Objectives/Cerf
-
- 0915 HEMS: Craig Partridge and Glenn Trewitt
-
- 1030 Break
-
- 1045 SGMP - Jeff Case
-
- 1145 CMIP/CMIS - Amatzia Ben-Artzi
-
- 1245 Lunch Break
-
- 1430 TCP/IP and ISO: Politics, Technology, Penetration/Cerf
-
- 1530 Break
-
- 1545 Tradeoffs among alternate paths (Discussion)
-
- 1700 Resolution of alternatives
-
- 1730 Summary of conclusions/actions
-
- 1800 Adjourn
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Cerf [Page 12]
-
- RFC 1052 Internet Management April 1988
-
-
- REFERENCES
-
- The following reference material was provided in advance of the
- meeting. Note that some of the citations include informal
- descriptors (such as IDEA numbers or DRAFT letter codes), for
- example, IDEA-13 or DRAFT-AAAA. IDEA notes may be updated from time
- to time reusing the same number. The IDEA notes are the working
- notes of the Engineering Task Force. The DRAFT is a temporary
- notation and may not be meaningful for more than a few months.
-
- HEMS
-
- (1) Craig Partridge, "A UNIX Implementation of HEMS", USENIX,
- February 1988. [Available from C. Partridge, BBN Labs]
-
- (2) Craig Partridge and Glenn Trewitt, "The High-Level Entity
- Management System", RFC-1021.
-
- (3) Craig Partridge and Glenn Trewitt, "The High-Level Entity
- Management Protocol", RFC-1022.
-
- (4) Glenn Trewitt and Craig Partridge, "The HEMS Monitoring and
- Control Language", RFC-1023.
-
- (5) Craig Partridge and Glenn Trewitt, "HEMS Variable
- Definitions", RFC-1024.
-
- (6) Craig Partridge and Glenn Trewitt, "The High-Level Entity
- Management System", IEEE Network magazine, March 1988.
-
- SGMP/SNMP
-
- (1) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
- Simple Gateway Monitoring Protocol", RFC-1028, November 1987.
-
- (2) James Davin, Jeff Case, Mark Fedor and Martin Schoffstall, "A
- Simple Network Management Protocol", IDEA-11, February 1988,
- obsoletes RFC-1028 when issued.
-
- (3) Jeffrey R. Case, James R. Davin, Mark S. Fedor, Martin L.
- Schoffstall, "Introduction to the Simple Gateway Monitoring
- Protocol", IEEE Network Magazine, March 1988.
-
- CMIS/CMIP
-
- (1) Amatzia Ben-Artzi, "Network Management for TCP/IP Network: An
- Overview", IDEA-12, February 1988.
-
-
-
-
- Cerf [Page 13]
-
- RFC 1052 Internet Management April 1988
-
-
- (2) Lee LaBarre, " TCP/IP Network Management Implementors
- Agreements", IDEA-13, January 1988.
-
- (3) Lee LaBarre, "Data Link Layer Management Information:
- MAC802.3", DRAFT-MMMM, February 1988.
-
- (4) Lee LaBarre, "Network Layer Management Information: IP",
- DRAFT-NNNN, February 1988.
-
- (5) Marshall Rose, "ISO Presentation Services on Top of TCP/IP-
- based Internets", DRAFT-PPPP, February 1988.
-
- (6) Lee LaBarre, "Structure and Identification of Management
- Information for the Internet", DRAFT-SMI, February 1988.
-
- (7) Lee LaBarre, "Transport Layer Management Information: TCP",
- DRAFT-TTTT, February 1988.
-
- (8) Lee LaBarre, "Transport Layer Management Information: UDP",
- DRAFT-UUUU, February 1988.
-
- (9) ISO/IEC JTC 1/21 N 2058, "2nd DP 9595-1 Information Processing
- Systems - Open Systems Interconnection - Management Information
- Service Definition - Part 1: Overview", December 1987.
-
- (10) ISO/IEC JTC 1/21 N 2059, "2nd DP 9595-2, Information
- Processing Systems - Open Systems Interconnection - Management
- Information Service Definition - Part 2: Common Management
- Information Service Definition", December 1987.
-
- (11) ISO/IEC JTC 1/21 N 2060, "2nd DP 9596-2, Information
- Processing Systems - Open Systems Interconnection - Management
- Information Protocol Specification - Part 2: Common Management
- Information Protocol", December 1987.
-
- (12) ISO/TC97/SC21/WG4 N 472, "US Comments on the Proposal for
- Extension of the Common Management Information Services and
- Protocol: Creation and Deletion Functions", November 1987.
-
- (13) JTC1/SC21/WG4 N 482, "Proposal to extend M-Set and M-
- Confirmed-Set to allow adding and removing values of a multi-
- valued attribute", November 1987.
-
- (14) S. Mark Klerer, "The OSI Management Architecture: An
- Overview", IEEE Network Magazine, March 1988.
-
-
-
-
-
-
- Cerf [Page 14]
-
-